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1 Property-irrelevant predicates 

Loops (and recursions) are major hurdles in scalability of property verification tools 
(verifiers). Although slicing removes loops which have no bearing on assert statement 
in terms of its value and reachability, sliced programs still have loops challenging scale 
up of the verifiers. If we can transform a program by eliminating some of such loops, 
it is more likely that a given verifier succeeds on transformed program. Of course the 
transformation will be useful only if results on transformed program can be used to get 
results on original program. 

Loops existing in a (backward) sliced program, may compute value of some vari¬ 
ables that impact outcome of assert expression in following ways: 

1. Impact on value of assert expression, possibly through a chain of assignments. 

2. Impact on value of some predicates, possibly through a chain of assignments, 
that 

(a) Value impact the assert statement 

(b) Influence the reachability of assert statement 

Obviously, loops of type (1) can not be eliminated, as they directly impact the value 
of assert expression. However, loops of type (2) can be eliminated if property can be 
checked even after abstracting the predicates which these loops are impacting. Since 
we want the transformed program to be useful in deciding the outcome on original 
program, ideally we would like the transformed program to be property equivalent to 
original program. So we focus on what kind of predicates can be abstracted so that 
loops and computations contributing to value of such predicates can be eliminated. 

Let C be a predicate in a given program P in which a property is encoded through 
an assert statement A. Let P' be an abstract program obtained from P by replacing 
right hand side of reaching definitions used for C, with a non deterministic value, 
denoted by 

Following observations are obvious: 

1. If predicate C is loop invariant in concrete program P then so it will be in abstract 
program P' too. 
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Figure 1: Abstracting non data impacting predicates 


2. If property holds in abstract program P' then it will hold in concrete program P 
also 

3. If property gets violated in abstract program P' then it may or may not get vio¬ 
lated in concrete program P. 

Predicate C is called irrelevant to property (ITP), if abstract program P' is prop¬ 
erty equivalent to concrete program P. 

Actually if one picks up any predicate C from concrete program P and generate 
abstract program P' in the manner mentioned above then case (1) and (2) will always 
hold. It is the case (3) which differentiates an arbitrary predicate from an ITP predi¬ 
cate. For predicate C to be ITP, in case (3), property should get violated in concrete 
program P also. 


2 Example 

In figure [I] we show a program annotated as (Concrete). If we abstract the predicate 
(t > 100) we will see that in resulting abstract program, annotated as (AbsProgl), 
property will hold and therefore (t > 100) is an ITP predicate. 

Considering predicate ( st==l ), we observe that in concrete program, st is loop 
invariant for outer while loop. We abstract this predicate also as explained above and 


2 







resulting abstract program is shown in Figure |T] with annotation (AbsPrg2). It is obvi¬ 
ous that the predicate (st== 1) is loop invariant in abstract program too. The property 
holds on this abstract program also and therefore ( st==l ) is an ITP predicate. 

Suppose we change the assignment to j at line 16 to j +=3 in concrete program. 
Now the assert will be violated in modified abstract program (AbsProg2), when one 
assigns a suitable value at non-deterministic assignment to st which makes predicate 
(st==l ) as false. And if an input exists with which st is assigned value 0 then it 
will get violated in concrete program also. It will not get violated in concrete program 
only if for no input st gets value 0. Which means predicate st==l always remains 
true in concrete program. 

3 A refined definition of ITP predicates 

To ensure that loops computing the value of an ITP predicate get eliminated, it will 
be good to place the non-deterministic assignments at only one point for a predicate 
rather than doing so at all reaching definitions individually. We choose this point as 
the nearest common post dominator of these reaching definitions. We claim that such 
a point exists and is unique. Without loss of generality, we assume that this point will 
be on a straight line segment of CFG(single entry, single exit). Let us call such a point 
as computing point of predicate C and denote it as C. In earlier example, we showed 
that when property holds in concrete program due to the predicate C being constant, 
say true, it may not hold in abstract program because the predicate C can be made 
false also in abstract program. Such predicates can never be ITP as per the earlier 
definition. Considering this fact, we refine our definition of ITP predicates using the 
modified abstraction strategy. 

Let C be a predicate in a given program P and let A be an assertion encoding a 
property to be checked in program P. Let P' be an abstract program obtained from 
(concrete)jtrogram P by inserting non-deterministic assignments at predicate comput¬ 
ing point C, for variables used in predicate C. The scheme is shown diagrammatically 
in Figure]^] As can be seen in Figure^ in abstract program P', point C is deemed to be 
after the placement of non-deterministic assignments. We claim that abstract program 
P' is a sound abstraction of concrete program P. We make following observations 
regarding this abstraction mechanism. 

1. Since abstract program P' is a sound abstraction of concrete program P, if prop¬ 
erty holds in abstract program P', it will hold in concrete program P also. 

2. If the property does not hold in abstract program P' then the counter example 
must follow one of the paths labeled as 2,5’,6’,7’. 

3. Execution traces which bypass predicate computing point C will be same in 
concrete as well as abstract program (shown by paths labels 1 and 2 in diagram). 
Consequently, if there is a counter example in abstract program P' bypassing C, 
like paths labeled (2) in Figure [2j then the same counter example will apply to 
concrete program P also. 
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Figure 2: Abstraction and program paths 


When we have a counter example trace passing throigh C, then the suffix of the 
trace starting with last occurrence of C will be called as violating-suffix. Obviously 
all the occurences of predicate C, if any, on the violating-suffix will evaluate to same 
value. A counter example trace will have a violating-suffix if and only if the trace 
passes through C. 

Definition 1 (Irrelevant to Property (ITP) Predicates) Predicate C is said to be ITP 
for the property encoded with assertion A when one of the following holds: 

1. If the property gets violated in abstract program P', with a counter example trace 
having a violating-suffix it then the property gets violated in concrete program 
P also with a counter example trace having a violating-suffix same as n. 

2. Property gets violated in abstract program P' with a counter example trace hav¬ 
ing a violating-suffix with C evaluating to b within the violating-suffix, and pred¬ 
icate C never evaluates to b in concrete program P. 

4 A sufficient criterion for ITP predicates 

From the Figure[2] it is clear that we need to identify the predicates for which, the value 
of assert expression as well as paths labeled as (5’,6’ and 7’) are not dictated by values 
of variables used in predicate C. Let Y denote set of such variables. In addition, the 
variables which dictate these paths and value of assert expression, should have same 
values at C in abstract program P' as well as in concrete program P. 

To formalise the idea we proceed as follows. In the rest of the discussion, we 
assume that program P is already sliced with respect to assertion A. Suppose we 
abstracted a given program P to abstract program P' with respect to a predicate C, as 
per the strategy mentioned earlier. Let the property be violated in abstract program P'. 
We want to know under what conditions we can say that it will be violated in concrete 
program P also. We need to consider only the case where counter example found in 
abstract program passes through the predicate computing point C. Let such a counter 
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example trace t' have program state o' at the last occurrence of predicate computing 
point C in r'. To be precise, o' is the program state just after the sequence of non- 
deterministic assignments placed at C. Let Y be set of variables used in predicate C. 
Let 7 r' be the violating-suffix of trace t', as shown in Figure [5] 

Let X' be set of variables whose value in o' determined the value of A and the 
violating-suffix o', excluding the control points corresponding to predicate C. Intu¬ 
itively, X' is the set of live variables at predicate computing point C, computed as 
follows: 

1. Start at A with variables used in A as initial set of live variables. 

2. Proceed along path o' up to C computing live variables at different nodes as per 
the traditional approach. 

3. Treat nodes corresponding to C as identity. 

Now, let us see what will it require to get a counter example in concrete program P 
also. There are two cases to be considered. 

Case 1: Violating-suffix o' bypasses condition C. 

Suppose we get a program state o in concrete program P at predicate computing 
point C such that it has same values of variables in X' as that in o'. Now the path 
taken in concrete program P, from C starting in state o will be same as o' and 
consequently, assertion A will get violated in concrete program P also. 

Case 2: Violating-suffix o' passes through condition C. 

Let b be the violating-value of predicate C. Suppose we get a program state 
o in concrete program P at predicate computing point C such that it has same 
values for variables in X' as that in o' and predicate C evaluates to b in state o. 
It may be noted that value of predicate C will not change till we do not revisit 
the predicate computing point C. Therefore, the path followed from C, starting 
from state cr will be same as o' and consequently, it will definitely make A get 
violated in concrete program P. 

We generalise above observations along two lines: 

1. We expand X' to X as set of live variables along all paths from predicate com¬ 
puting point C to assertion point A (with the restriction that C does not repeat on 
these paths). 

2. Rather than looking for a state cr having same X' restriction as that of o' , we 
consider restriction of all states at C with respect to X( generalisation of X') in 
abstract program P' as well as in concrete program P. 

To formalise, let S' and E be set of program states at C in abstract program P' and 
concrete program P respectively. Let Ej C E be set of states in which expression of 
predicate C evaluates to b £ {true, false}. We claim as follows: 

Claim 1 If for a predicate C, both of the following hold then C is ITP. 
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(51) |e'Ja- = |£Ja 

(52) Mb £ {true, false}. E & f 0 =» |_ s bjA = L^Ja 
Proof 1 We will consider two cases: 

Case 1: The counter example in P' bypasses the predicate C. 

By the precondition (SI) of the claim, [E'Jx = [^Ja- Since E' ^ 0, there will 
be a state a £ E at C in concrete program P such that X restriction of a' will be 
same as X restriction of a. Therefore path followed from a in concrete program 
P will be exactly same as violating-suffix it' and so assertion A will get violated. 

Case 2: The counter example in P' passes through C. 

Let b be the violating-value of predicate C. If C always evaluates to constant —*b 
in concrete program P then C is ITP as per the definition ??. So we assume 
that C evaluates to b also sometimes. Therefore 0. And consequently, by 

(S2) and (SI), [EbJ.Y = [Y 1 \x By similar argument as that in case (1), we can 
show that assertion A will get violated in concrete program P also.. 


5 A computable criterion for ITP predicates 

Given an assert A in a program P, we want to identify predicates in program P which 
satisfy the two conditions of claim |T] In these conditions, we talk about values of X 
and Y in all program states at predicate computing point C. 

First we consider the condition (SI), [E'J x = L^Ja. We observe that starting 
from same initial state, the program state, restricted to X, at C at its first occurrence 
in a trace will be same in abstract program P' and the concrete program P, provided 
X and Y are disjoint. Subsequent changes to program states, restricted to X, at C 
will be result of its transformation along the looping paths from this occurrence of C 
to its next occurrence. We observe that the only difference on paths followed from 
one occurrence of C to its next occurrence in P and P' is new abstract assignments 
inserted for Y at C in abstract program P'. Let Z be the set of live variables at C after 
traversing all paths from one occurrence of C to its next occurrence, after starting with 
X as set of live variables at C. It is easy to see that if Z is disjoint from Y then the 
transformation of X from one occurrence of C to its next occurrence will be in same 
manner in concrete program as well as abstract program. 

Claim 2 If following two conditions are satisfied then value of X at C will be same in 
Pand P'. 

(Cl) X and Y are disjoint. 

(C2) The set of live variables on paths from C to C with respect to ( X , C) is disjoint 
from Y. 

Now we consider the criterion (S2) |_E{,Jjy = LSJa. Intuitively, this condition 
requires that every A' restricted state of E is some X restricted state of E& also. Since 
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Figure 3: Illustration of values getting related 


set of states Ef, will be decided by values of Y, intuitively, this criteria can be met when 
X and Y get their values in independent manner. That is they are not related in any 
manner when computation proceeds from ENTRY to C. 

Consider programs given in Figure [3] In program (a), values of x and y at line 5 
get related (they will be same as z). In program (b) values of x and y get related as 
they change together in the enclosing loop. In program (c) values of x and y are not 
related. 

Intuitively, we can achieve independence of X and Y by ensuring following: 

1. No computation impacts value of both X as well as Y. 

2. Values of ( X, C) and (Y, C) do not change together in different iterations of any 
loop enclosing C. 

So now we will derive computable criteria which will satisfy these two require¬ 
ments individually and then show that together they are sufficient to ensure (S2). 

5.1 Non interfering computations 

We observe that only the computations in value slice of (V, l) may affect value of (V, £). 
So obviously we need to consider the common computations belonging to value slice 
of (X, C) as well as to that of (Y, C). But when we want to see if values of (A', C) and 
(Y, C ) may get affected by a common computation, we need to look at computations 
which provide values to predicates that only control reachability of C but otherwise 
are not common to value slice of (X,£) and (Y,C). This is because, a controlling 
predicate in a way restricts the values of variables participating in the predicate, along 
the true and false branches. If such variables, later take part in computations which 
affect the value of (A, C) as well as (Y, C) then the computations which provide value 
to such predicates, should be considered as candidates affecting the value of (A, C) as 
well as (Y, C). 

To illustrate, consider programs of Figure [4] In both programs (a) and (b), predi¬ 
cates Q i at line 1 and Q 2 at line 4 are controlling the reachability of predicate comput¬ 
ing point C at line 7. We notice that, in program (a), through value of variable z at Q \, 
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predicate Q i will restrict the value of x at G. Similarly, value of z at Q\ will also play 
a role in predicate Q 2 restricting the value of y at C (assuming value of z does not get 
reassigned from Q \ to Qf). As a result, in program (a), computation of z before Q \ 
is relating value of x and y at C through predicates Q\ and Q 2 . However, in program 
(b), it is value of variable zl which plays a role in predicate Qi restricting value of x 
at C and it is value of variable z 2 which plays a role in predicate Q 2 restricting value 
of y at C. As a result value of x and y at C do not get related due to () \ and Q 2 in 
program (b). 

To find out whether some computation relates values of (X, G ) and (Y, G), we will 
extend the concept of value impacting statement and call it extended value impacting. 
A predicate which controls the reachability of point of interest and uses same definition 
of a variable which is used by a value impacting node, is also treated as a value im¬ 
pacting node. For example, in program(a) of Figure[4j predicate Q 2 uses same value of 
y as that used in value impacting assignment y=y+l for (y, C). Therefore, predicate 
Q 2 is also considered as value impacting for ( y,C). Similarly predicate Q\ will be 
considered as value impacting for (x,C). 

Definition 2 (Extended Value-impacting node) A node s extended-value-impacts T = 
(l, V), if any of the following conditions hold: 

1. s is an assignment in DU(T). 

2. s is an assignment, and there exists a node t such that t extended-value-impacts T 
and s is in DU(LV(t)). 

3. s is a predicate cfrom w’hich there exist paths 7 Ti and n 2 starting with the out-edges 
ofc and ending at the first occurrence ofl. Further, there exists a node t c such that 
t extended-value-impacts T, and (a) t is the first value-impacting node along tt\ (b) t 
is not the first value-impacting node along 7 r 2 . 

4. s is a predicate c which transitively controls l. Further, there exists an extended- 
value-impacting node t 7 ^ c and an assignment d such that d is in DU {LV (t)) and d 
is in DU {LV (c)). 

A slice made up from extended value impacting statements, will be called extended 
value slice. We know that in a program which is already (backward) sliced with re¬ 
spect to (V,£), only variables which are live at ENTRY point dictate the value of 
(V, £) and reachability of l. Similarly, in an extended value slice with respect to (V, l), 
variables live at ENTRY point will dictate value of ( V, /:), whenever (is reached. For 
extended value slice we will call these variable as value base of ( V, l) and denote them 
as VB{V,£). We will denote the set of extended value impacting nodes for (V, £) by 

EVI(V,£). 

We claim that if set of value base variables for {X, C) and (Y, G) are disjoint then 
no computation affects value of both when C is not enclosed in a loop. 

(C3) VB{X, C) n VB(Y, G) = 0 

5.2 Avoiding relation through loops 

To find a criterion which ensures that value of ( X, C) and (Y, C) do not become related 
due to they changing together in a loop L, we need to see how to identify if some 
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(a) (Interfering) (b) (Non-interfering) 


Figure 4: Interference of control conditions with values 


variable is changing in a loop. 

Suppose we observe value of a set of variables Z at a point i which is inside a loop 
L. Let [L] represent the body of loop L and VB(L) denote the value base variables of 
loop controlling condition of loop L. Let EV l( Z. t) be set of extended value impacting 
statements for (Z,£). We claim that value of Z at t may change with different iterations 
of loop L only if at least one extended value impacting statement from h'VI(Z. t) is 
outside the body of loop L and at least one such statement is inside the loop body. Let 

us call such loops as value changing loops for (Z, t). That is if EVI(Z , £) (~1 [L] ^ 0 

and EVI(Z,£) C [£,] then only (Z, t) can change its value in different iterations of 
loop L. 

So to ensure that value of ( X , C) and (Y. C) do not change together in any enclos¬ 
ing loop of C, following criterion (C4) should be satisfied. 

(C4) For all loop L enclosing G, one of the following should hold. 

(a) (EVI(X,d) n [L] = 0) V (EVI{X,d) C [L]) 

(b) (EVI(Y,C) n [L] = 0) V ( EVI(Y,d )) C [L]) 

We observe that, if value of ( V. £) changes in different iterations of a loop L then 
loop controlling conditions of all outer loops (enclosing loop L) will be value impacting 
node of (V, t). Based on this observation and criterion (C4) about value changing 
loops, we have following properties for value changing loops of (X, C) and ( Y , C). 

(PI) if (X,C) changes in a loop L then for all outer loops L’ of L, VB(L') (T 
VB(X, C) = 0 V VB{L') C VB{X, C). 

(P2) if (Y, C) changes in a loop L then for all outer loops L' of L, VB(L') (T 
VB(Y, C) = 0 V VB{L') C VB(Y, C). 

(P3) if ( X , C) changes in a loop L\ and (Y, C) changes in a loop L 2 then VB{L\) 
and VB{Ij 2 ) are disjoint. 
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(P4) if (X, C) changes in an inner loop then VB(L ) C VB(X, C). 

(P5) if ( Y, C) changes in an inner loop then VB(L) C VB(Y, C). 

Claim 3 If criteria (C3) and (C4) hold for a predicate C then following will hold: 
V 6 G {true, false }.£ b 7 ^ 0 => |_ s b.U = L S _U 

Proof 2 Let X and Y be the set of value base variables for (X, C) and ( Y , C) respec¬ 
tively. In addition let V be the set of all variables. Let Z = V — ( X U Y ). Obviously, 
X, Y and Z are disjoint. 

Assume that b is true and Y true 7 ^ 0- Suppose a G S and at G Y true . Let input 
state I\ produce a and I 2 produce at- We partition I\ into |_iij [/ij p and |_/ij sf. 
Similarly, we partition / 2 into |_/ 2 J x j L^J y an d \Ji\ %■ 

Let VB{L) denote the base variables for loop controlling conditions of loop L. We 
construct an input I 3 such that values of X come from I\ and those for Y come from 
/ 2 - For the remaining values we proceed as follows: 

For each loop L enclosing C, ifVB(L) is not included in X or Y then we proceed 
as follows: 

1. If (X, C ) changes in L then use values ofVB(L)from I\. 

2. If (Y, C) changes in L then use values ofVB(L)from J 2 . 

3. If none of (X, C ) and (Y, C) changes in L then use values ofVB{L)from I\ 

By the properties (PI) to (P5), such assignments will be possible without any conflict. 
That is no variable will be required to have it value from I\ as well as from / 2 . By 
the above step, some of variables from Z would have got their input values. For the 
remaining variables of Z, if any, take their values from I\. Obviously starting with 
input I 3 , C will be reachable, with value of X at C same as that with ij and value o£ 
Y at C same as that with I 2 . Therefore, one of the states produced with input I 3 at C 
will have same values of X as that in a and same values ofY as that in a t . Let 03 be 
such a state. Obviously C will evaluate to true in state 03 and therefore <73 G Y true . 
Moreover \cr\x = | cr, 3 J x- Therefore |_EJx C [£ true J A -. similarly we can show that 

LEJx c [Yf a i se \X- 

It is obvious that checking the criteria (Cl), (C2), (C3) and (C4) is computable for 
a given predicate C. 

6 Property checking with ITP predicates 

Assume that we identified an ITP predicate C in program P as per the definition |T| 
We abstract P to P' using the abstraction strategy mentioned earlier. Now we run a 
property checker on program P'. We consider following cases: 

(i) Property holds in P'. 

(ii) Property gets violated with a counter example bypassing C. 
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(iii) Property is violated in P' with counter example passing through C. 

For case (i), we are done as the property will hold in program P also. For case (ii), the 
property will get violated in P also with same counter example as that of P\ as per the 
property of the abstraction mechanism. The case (iii) needs to be analysed further and 
we proceed as follows: 

Let input /' be the the counter example, producing trace r', for abstract program 
P'. Since the counter example trace passes through C, it will have a violatinng-suffix, 
say 7 r. We execute program P with same input /' to get trace r and consider following 
possible outcomes for trace r. 

1. Assertion is violated. 

2. Assertion is not violated and trace t' bypasses the condition C. 

3. Assertion is not violated in trace r and trace t' passes through C with violating - 
value of C as b £ {true, false}. 

If it is case (1) then we are done as we found a counter example in concrete program P 
also. For case (3) we consider following sub cases: 

3(a) Trace r never passed through C. 

3(b) Trace r, passed through C and C evaluated to b at least once. 

3(c) Trace r passed through C but C always evaluated to —h. 

If it is case 2, 3(a) or 3(c), we want to check the possibility of C always evaluating to 
-i b in program P. For this, we create a program P from P by placing a new assert 
expression (C == ->b) at C and removing the old assert. We also replace predicate C 
with ~h. We claim that assertion in P will hold if and only if C always evaluated to ~b 
in program P. We solve the new property checking problem P and consider following 
possible outcomes. 

(A) New property does not hold in P, implying that the predicate C evaluates to b 
also sometimes. 

(B) New property in P holds implying C always evaluates to —ib. 

In case (B), we create a new property checking problem P from P by replacing C with 
-i b. Problem P will be property equivalent to P. Solving P will give solution to P. 

For the cases (A) and 3(b), by definition [I] of ITP predicates, we know that, for 
program P , there exists a counter example trace which has a violating-suffix match¬ 
ing with violating-suffix 7r of counter example trace of P'. We compute a weakest- 
precondition ip of -.4 for the path tt. Obviously, ip must be satishable at C in P. So 
there must exist an input for program P which satisfies ip at C and the same will indeed 
be a countre example in P for assertion A. 

So we just need to find a counter example which violates the assertion -up at C. 
So, we create an input generation problem as property checking for the assertion ->ip 
in program P at C. Obviously, this assertion must get violated and if verifier finds 
an input for the same, it will be counter example for the original property checking 
problem. 


11 


